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OBJECTIVE 


Investigate  the  technological  capabilities  demonstrated  by  LADDER.  Provide  insights 
into  advanced  concepts  contributing  to  the  enhancement  of  query  systems  in  general. 


RESULTS 

1 . Maintaining  large  lists  of  proper  names  in  a grammar  is  unnecessary  and  wasteful 
because  of  the  specificity  of  operational  contexts.  It  is  more  logical  to  base  the  placement  of 
identifiers  in  the  grammar  on  user-system  interactions,  supporting  particular  contexts  as 
required. 

2.  Adaptation  of  grammatical  constructs  and  internal  views  of  data  base  structure 
can  be  developed  to  reflect  user-oriented  contexts.  Interactive  and  automatic  generation  of 
profiles  for  information  retrieval  tasks  can  assist  the  user  by  anticipating  his  information 
requirements. 

3.  Development  of  software  to  profile  an  individual’s  capabilities  and  approaches 
for  solving  problems  in  specific  tasks  can  further  assist  the  user.  Such  software  can  provide 
a "user  friendly”  environment  one  that  is  tailored  to  each  individual  in  which  to  per- 
form those  tasks. 

4.  Taken  together,  these  conclusions  form  the  basis  for  conceptualization  of 
“intelligent”  query  systems  or  “intelligent  assistants”  that  can  delineate  the  scope  of  an  in- 
formation retrieval  task,  can  perform  routine,  preliminary  footwork  to  establish  situation 
contexts  for  the  user,  and  can  provide  assistance  to  user  interactions  and  query  processing 
through  intelligent  guidance  and  organization  of  information. 

RECOMMENDATIONS 

1.  Use  LADDER  as  a tool  to  investigate  these  concepts  in  experiments  with 
actual  users. 

2.  Conduct  such  investigations  to  validate  the  theoretical  foundation  for  these 


concepts  and  to  examine  resulting  effects  on  performance  of  information  retrieval  tasks. 
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INTRODUCTION 


During  FY  78.  the  LADDFR  (language  access  to  distributed  data  with  error  re- 
covers ) natural  language  query  system  was  evaluated  in  the  Advanced  Command  and 
Control  Architectural  Testbed  (ACC AT)  facility  at  NOSC  San  Diego.  The  operational 
utility  of  LADDER  with  respect  to  command  and  control  applications  was  assessed  in  an 
experiment  using  Navy  officers  as  subjects  (ref  1).  A second  effort,  the  subject  of  this 
report.considered  the  technological  capabilities  demonstrated  by  LADDFR  and  provided 
insights  into  advanced  concepts  contributing  to  the  enhancement  of  query  systems  in 
general. 

The  use  of  natural  language  for  querying  data  bases  has  been  a widely  researched 
issue  for  a number  of  years  (see  natural  language  bibliography).  Although  several  experi- 
mental systems  have  resulted  from  this  research  (ref  2-4).  few  have  been  applied  to  the 
operational  needs  of  specific  users.  One  exception  is  the  LADDFR  (language  access  to 
distributed  data  with  error  recovery)  system,  which  was  developed  as  a management  aid 
to  Navy  decision  makers  by  SRI  International  (ref  5). 

Underlying  capabilities  of  LADDFR.  however,  exhibit  a range  of  application  much 
broader  than  it  was  designed  for.  LADDFR  is  therefore  useful  for  the  evaluation  of  query 
system  features  in  general  as  well  as  natural  language  systems. 

NOSC.  San  Diego,  performed  rather  extensive  test  and  evaluation  of  the  LADDFR 
system  during  FY  78  as  part  of  the  ACC AT  project,  jointly  funded  by  DARPA  and 
NAVI  FI  \.  The  evaluation  progressed  along  two  mutually  supportive  assessments:  ( 1 ) the 
operational  utility  of  LADDFR  with  respect  to  its  interactions  with  Navy  users,  and  (2) 
current  and  advanced  capabilities  of  LADDF  R deemed  appropriate  to  Navy  command  con- 
trol systems  The  first  assessment  (ref  I)  provided  valuable  insights  into  the  utility  of  a 
natural  language  system  and  indicated  unexpected  eccentricities  in  the  man-computer 
dialogue.  I'his  report  focuses  on  the  second  assessment.  It  addresses  a number  of  issues 
that  could  ultimately  enhance  the  operational  use  of  LADDFR.  In  fact,  many  features 
discussed  herein  are  not  restricted  to  LADDF  R.  or  even  to  natural-language-based  systems. 
Concepts  of  particular  interest  deal  with  user  interactions,  certain  grammatical  constructs, 
and  data  access  techniques.  These  concepts  imply  a query  system  design  which  emphasizes 
user  supportive  responsibilities  of  the  query  system  and  of  the  data  base  management 
system. 


1 . NOSC  Code  832 1 hr  rpt.  Performance  of  a Natural  Language  Query  System  in  a Simulated  Com- 
mand Control  Pnvironment.  by  HO  Miller.  RL  llersltman.  and  RT  Kelly.  May  I '>78. 

2.  Rl  Qt  1ST:  \ Natural  I anguage  Question-Answering  System,  by  \VJ  I’lath:  II  i Journal  of  Research 
and  Development,  vol  20.  July  1 07(\  p 326-335. 

3.  An  Fnglish  I anguage  Question  Answering  System  for  a Large  Relational  Database,  by  1)1  Waltz; 
Communications  of  the  ACM,  vol  2 I no  7.  July  ll, 2 3 * 578.  p 526-5  3l>. 

4 BBN  Report  2378,  The  Lunar  Sciences  Natural  l anguage  Information  System.  Final  Report,  by 
W’A  Woods.  RA  Kaplan,  and  B Nash-Webber.  Bolt.  Betanek  and  Newman.  Inc.  Cambridge  MA. 

I ‘>72. 

5.  Final  Technical  Report,  Project  4763,  Mechanical  Intelligence  Research  and  Applications,  by  I D 
Sacerdoti  (ed);  SRI  International.  Menlo  Park  CA.  December  I 7 7 . 


rh is  report  is  conceptual  and  is  not  to  he  construed  as  a preliminary  statement  of 
lunctional  specitications  tor  a Navy  query  system.  However,  a fundamental  goal  of 
AC  C'Al  is  to  “shape  and  influence  the  research  and  development  of  appropriate 
information  processing  technology  such  that  it  is  potentially  transferable  to  the  Navy 
tor  command  control  applications"  (ref  o).  Opinions  of  the  operational  community 
need  to  be  shared  with  researchers  throughout  the  evaluation  process.  1 his  report  is 
one  attempt  to  till  that  need. 

LADDER  has  been  established  as  an  extremely  flexible  tool  for  the  investigation 
of  query  sy  stem  features.  It  will  be  used  in  future  experiments  w ith  operational  personnel 
to  test  alternatives  to  a purely  natural  language  front  end.  Nearly  all  of  the  features  and  en- 
hancements described  herein  are  considered  to  be  within  the  state  of  the  art  in  artificial 
intelligence  and  information  processing  and  could  conceivably  be  demonstrated  by  using  the 
LADDI  K system.  (As  will  be  explained,  some  of  these  features  have  already  been  demon- 
strated.) Much  ol  LADDliR's  evolutionary  growth  has  been  in  response  to  experimental 
results  and  observations  from  NOSC  analy  sts,  illustrating  that  interaction  between  research 
and  operational  communities  in  the  early  stages  of  system  development  can  prove 
beneficial. 


INTELLIGENT  INTERPRETATION  OF  USER  INPUTS 

A natural  language  system  such  as  LADDER  faces  a much  greater  challenge  m cor- 
rectly interpreting  user  inputs  than  do  the  menu  select,  function  key  or  structured  English 
approaches,  in  which  the  range  of  input  is  generally  well-defined  and  can  be  readily  antici- 
pated by  the  sy  stem.  The  inherent  flexibility  of  natural  language  prohibits  the  sy  stem  from 
I knowing  what  to  expect  when  a user  initially  interacts  with  the  system  or  as  he  proceeds 

from  one  query  to  the  next.  Even  though  LADDER  is  concerned  with  a specific  conceptual 
domain  Navy  command  and  control  and  thereby  limits  query  context  somewhat,  the 
structure  of  user  inputs  is  seemingly  endless,  v ary  ing  from  simplistic  “unnatural”  queries 
! ("WHAT  NATION  PECOS  ')  to  more  complicated  structures  ("WHAT  SHIPS  WITHIN 

500  MILES  OF  Till  PECOS  HAVE  A DOCTOR  ABOARD")  (ref  I > I ADDI  R developers 
attempted  to  overcome  this  problem  by  providing  (Da  reasonable  coverage  of  user  sy  ntax 
with  respect  to  the  given  context  (semantically  -oriented  grammar  (ref  5 ))  and  (2)  the  capa- 
bility for  grammar  expansion,  to  incorporate  specific'  user-idiosyncratic  constructs.  These 
two  provisions  together  prov  ide  the  user  with  total  sy  ntactic  coverage,  although  for  complex 
structures  he  must  have  considerable  knowledge  of  the  generative  methodology  for  the 
grammar.  (In  such  cases  personnel  responsible  for  system  maintenance  generally  are  called 
upon  for  assistance.)  Maximum  sy  ntactic  coverage  can  best  be  provided  through  extensive 
system  testing  at  operational  command  and  control  centers,  where  users  interact  with  the 
system  in  their  own  jargon  and  task-related  terms.  Grammatical  modifications  would  then 
reflect  user-specific  requirements.  Although  it  would  be  desirable  for  such  testing  to  be  done 
in  simulated  command  and  control  centers  in  the  NOSC  ACCAT  facility . there  is  no  way 
to  duplicate  the  variety  of  situations  and  information  retrieval  requests  that  occur  in  the 
actual  environment. 

One  implementation  issue  facing  LADDER  as  well  as  other  query  systems  (particu- 
larly those  providing  some  form  of  automatic  v alidation  of  user  input ) is  the  inclusion  of 
proper  names  (ships,  ports,  aircraft  types,  surface  tracks,  etc)  or  identification  codes  in  the 
grammar  itself.  Specification  of  unique  identifiers  serves  a number  of  useful  purposes. 

I Examples: 

Incorrect  spellings  often  can  be  recognized  and  corrected. 


6.  NOSC  Code  S.t  ’ I In  rpt.  Advanced  Command  and  Contiol  Arehiteetmal  Testbed  Concept  of 
Operations  Plan. vol  I.Julv  D77. 
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The  context  of  the  query  can  be  deduced  by  recognizing  the  classification  or 

category  to  which  the  identifier  belongs. 

Implicit  assignment  of  context  based  on  the  interpretation  of  identifiers  enhances  data  re- 
trieval by  supporting  the  translation  of  user  input  to  commands  understood  by  the  data  base 
management  system.  The  context  designates  what  files  are  to  be  accessed  and  what  attributes 
or  fields  are  to  be  retrieved.  For  example,  although  the  attribute.  MAXIMUM  SPEF.D.  is  ap- 
plicable to  both  ships  and  aircraft,  each  file  might  have  its  own  name  (eg  MAXSPEFD  in  the 
aircraft  file.  MCSF  in  the  ship  file).  Recognition  of  the  object  provides  the  appropriate  con- 
text from  which  the  data  base  query  can  be  generated.  Without  this  information,  the  query 
system  would  be  forced  to  search  several  files  for  the  specified  identifier.  If  the  grammar  is 
to  recognize  identifiers,  however,  it  must  maintain  lists  containing  potentially  thousands  of 
such  items.  This  places  a tremendous  burden  on  the  system  developers  and  the  computing 
resources.  Moreover,  provision  must  be  made  for  the  updating  of  dynamic  elements  (flights, 
surface  tracks,  air  tracks,  etc)  either  through  direct  interaction  with  the  data  base  manage- 
ment system,  in  response  to  the  presence  of  certain  "alert"  criteria,  or  through  operator 
action  based  on  other  sources  of  information  or  on  operator  knowledge  of  values  stored  in 
the  data  base.  The  latter  method  places  considerable  burden  on  the  user  and  increases  the 
likelihood  that  inconsistencies  could  arise  between  the  data  base  and  the  grammar’s 
knowledge. 

An  apparent  dichotomy  exists:  the  grammar  should  be  smart  enough  to  recognize 
and  understand  (ie  determine  the  context  for)  proper  names  of  static  and  dynamic  objects, 
but  should  not  have  to  maintain  gigantic  lists  of  such  names,  that  is.  to  remember  what  the  ob- 
jects are  and  what  they  are  called.  A partial  resolution  of  this  problem  is  suggested  by  con- 
sidering the  user  environment  in  which  LADDER  or  some  other  query  system  might  be 
employed.  Very  simply,  no  operator  will  require  information  on  all  objects  in  the  data  base 
at  any  one  time  (if  ever).  Instead,  each  command  and  control  center  is  concerned  with  a 
specific  area  of  interest  and  with  a limited  subset  of  information  contained  in  the  data  base. 
Suppose,  then,  that  the  query  system  has  no  a priori  knowledge  of  object  identifiers  but  will 
leant  them  through  interaction  with  the  user.  For  example,  an  operator  may  ask.  "WHERE 
IS  THE  CONSTELLATION?"  In  LADDER,  the  query  cannot  be  parsed  unless  the  name  is 
in  the  grammar.  More  appropriately,  the  query  system  could  respond  as  follows: 

THE  IDENTIFIER.  CONSTELLATION.  IS  NOT 

RECOGNIZED  BY  THE  SYSTEM. 

DOES  IT  DEFINE  A 

A.  SHIP? 

B.  PORT? 

C.  AIR  TRACK  ? 

D.  SURFACE  TRACK? 


The  user  then  specifies  the  intended  interpretation,  whereupon  the  system  can  properly 
categorize  the  name  and  formulate  data  retrieval  commands  for  processing  by  the  data  base 
management  system.  The  identifier  would  become  a permanent  element  in  the  grammar 
(at  least  for  the  duration  of  the  current  transaction),  available  for  use  in  subsequent  queries 
without  further  specification. 


Query  responses  also  contain  information  relating  to  the  user’s  context.  It  an  oper- 
ator asks  "WHAT  SHIPS  ARl  WITHIN  500  MIFFS  OF  NAPLES?”  he  is  obviously  indicating 
some  interest  in  the  ship  names  which  will  he  returned.  This  list  ol  names  can  be  intercepted 
briefly  In  the  query  system,  to  incorporate  these  names  into  the  grammar,  then  passed  on  to 
the  user.  By  these  two  methods  interacting  with  a user  to  provide  interpretation  ot  un- 
known object  names  and  presuming  that  response  information  reflects  the  user's  scope  of 
interest  a contextual  framework  is  generated  within  the  grammer  for  that  particular  trans- 
action. fins  modified  grammar  will  be  referred  to  as  a "contextual”  grammar.  Instead  of 
the  grammar’s  having  to  be  so  general  as  to  require  no  human  assistance  in  understanding 
queries,  the  system  becomes  adaptive,  responding  to  the  needs  of  specific  users  or  classes  of 
users.  Once  defined,  a contextual  grammar  can  be  preserved  for  later  reference.  A com- 
mand and  control  center  could  conceivably  possess  a library  of  such  grammars,  each  ap- 
propriate to  specific  tasks  of  indiv  idual  users  (eg  routine  reports  or  briefings  I or  to  overall 
missions  assigned  to  a staff  of  users  (eg  transit  planning,  search  and  rescue  operations,  etc). 
Contextual  grammars  are  fundamental  to  the  concept  of  mission  profiles,  to  be  discussed 
later  in  this  section. 

Some  problems  are  anticipated  in  implementing  an  adaptive  grammatical  scheme  as 
introduced  above,  first,  the  specified  name  in  a query  (eg  "CONST!  LI  ATIOV'I  might  not 
be  a valid  name  in  the  data  base,  l o illustrate  this  situation,  suppose  a user  inquires  about 
the  carrier  JOHN  T.  KENNEDY.  although  the  name  stored  in  the  data  base  is  really 
"KENNEDY  JF”  or  even  “JFK.”  The  data  base  management  sy  stem  would  be  unable  to 
find  any  data  for  the  “JOHN  F.  KENNEDY."  A possible  solution  is  to  create  a list  of  trans- 
lations from  “synonyms"  to  proper  data  base  values.  Although  this  list  of  associated  names 
could  conceivably  become  quite  large  in  contrast  to  the  grammar  it  may  be  desirable  to 
create  just  one  such  file  for  all  names  its  relative  stability  would  permit  efficient  structur- 
ing of  the  data  for  rapid  access  of  any  record.  Uncommon,  user-speeitic  sy  nonyms  such  as 
"MYBOAT"  for  "CONST!  1 I ATION"  could  be  defined  in  the  grammar  itself  (l  ADDER 
has  this  capability),  so  that  an  initial  translation  to  a common  name  can  occur  when  the 
query  is  parsed.  Morever.  following  interaction  with  the  data  base  management  sy  stem,  the 
actual  data  base  value  could  be  substituted  for  the  common  name,  providing  a one-step  trans- 
lation to  a value  consistent  with  the  data.  This  procedure  would  preserve  the  stability  of  the 
tile  of  associated  names,  would  save  query  processing  time  for  future  references  to  that  name, 
and  would  contribute  to  the  concept  of  grammatical  adaptation  to  the  user's  specific  needs 

A second  problem  involves  the  definition  of  appropriate  query  sy  ntaxes  that  would 
incorporate  unknown  or  indefinite  patterns.  When  the  input  is  parsed,  the  presence  of  these 
patterns  would  cause  the  system  to  initiate  interaction  with  the  user  to  determine  the  proper 
interpretation  of  unknown  identifiers.  Investigations  at  NOSC  ACC  AT  have  demonstrated 
the  feasibility  of  this  approach  through  definition  of  a top-level  pattern  in  1 ADDI  R 
(WHAT)  <BI  > (ATTRIBUTE)  (OF)  (INOI  I . NAM  I ' 
where  INDEF.NAMI  can  be  matched  by  a variety  of  words  or  phrases,  such  as 

( 1 ) a known  (ie  already  listed  in  the  grammar)  ship.  port,  track,  flight,  etc 

(2)  VESSEL  name 
FLlCiHT  number 
TRACK  NUMBER  identifier 

(Here,  the  name  or  identifier  is  qualified  by  an  explicit  descriptor  It  the  name 
is  not  known  to  the  grammar,  it  is  automatically  added  to  the  appropriate  list.) 

(5)  an  arbitrary  word  or  phrase 


o 


I 


In  item  ( 1 ) no  interaction  with  the  user  is  necessary;  the  object  name  has  been  defined  pre- 
viously. In  item  (2)  the  same  is  true  if  the  object  name  is  known  to  the  grammar;  otherwise, 
the  system  may  want  to  ask  for  confirmation  from  the  user  (in  case  of  spelling  error)  before 
placing  the  name  into  its  proper  category.  To  handle  item  (3),  the  system  interacts  with  the 
user  in  a manner  similar  to  that  shown  e;*' her.  Grammatical  modifications  used  to  perform 
these  actions  are  given  in  appendix  A. 

The  same  principle  applies  to  an  indefinite  name  that  occurs  in  the  interior  of  a 
query  (eg  "HOW  FAR  IS  XYZ  FROM  HONOLULU  .’”).  In  LADDER,  the  parser  would  be 
unable  to  continue  past  the  word  "XYZ."  assuming  it  is  not  part  of  the  grammar.  At  that 
point,  it  may  be  possible  to  present  the  query  tail  “XYZ  FROM  HONOLULU'  to  the  operator, 
to  ask  him  to  enter  the  word  (or  phrase)  he  intended  to  use  as  the  object  name,  to  ask  for 
definition  (categorization)  of  the  object  name,  to  enter  the  name  into  the  appropriate  cate- 
gory. to  remove  the  word(s)  from  the  left  end  of  the  tail,  then  to  proceed  with  the  parsing. 
Although  the  programming  details  are  not  trivial,  this  approach  appears  feasible.  Top-level 
syntaxes  (at  least  in  a LADDER-like  system)  would  become  more  general,  with  context- 
specific  patterns  (eg  (SHIP)  and  (PORT))  replaced  by  (INDF.F. NAME)  productions.  In  this 
respect,  the  grammar  may  become  easier  to  modify  and  maintain. 

In  the  above  discussion,  it  was  contended  that  recognition  of  context  facilitates  trans- 
lation of  user  input  into  the  language  of  the  data  base  management  system.  In  LADDER, 
user  queries  are  actually  translated  to  an  intermediate  language,  called  the  IDA  (Intelligent 
Data  Access)  query  language,  which  is  then  used  by  the  IDA  subsystem  to  generate  Data- 
language  (ref  5,  7.  8).  Unless  the  context  is  recognized,  the  query  "WHAT  IS  THE  SPEED 
OF  XYZ?”  is  difficult  to  translate.  If  XYZ  is  a known  ship,  for  example,  the  query  should  be 
translated  to  the  IDA  query 

(?  PTS)  (NAM  F.Q  XYZ’). 

To  obtain  the  answer,  the  resulting  Datalanguage  would  calculate  the  join  of  the  SHIP  and 
TRACKHIST  relations  by  using  the  common  attribute  of  UIC  (Unit  Identification  Code)  or 
VC'N  (Vessel  Control  Number).  If  XYZ  is  an  air  track  identifier,  on  the  other  hand,  a second- 
ary translation  of  attribute  PTS  (the  only  grammatical  translation  of  the  word  "SPEED”)  is 
necessary  to  access  attribute  SPEED  of  the  AIRTRACK  relation.  Thus,  although  IDA  may 
receive  the  query 

(?  PTS)  (ATRAC'K  EQ  ‘XYZ’), 

it  (currently  ) will  not  generate  correct  Datalanguage.  even  though  IDA  knows  that  SPEED 
is  the  synonym  for  PTS  in  the  AIRTRACK  relation.  If  the  front-end  grammar  were  to  be- 
come more  aware  of  the  context,  the  problem  could  be  avoided  completely  by  issuing  the 
proper  query 

<?  SPEED)  (ATRACK  EQ  XYZ') 

to  IDA.  explicitly  indicating  what  file  to  access  to  obtain  the  response. 

Ambiguity  resolution  clearly  represents  one  of  the  most  difficult  problem  areas  in  a 
natural  language  system.  Given  a query  satisfying  more  than  one  interpretation,  LADDER 
does  have  the  capability  of  displaying  possible  interpretations  to  the  user,  who  can  there- 
upon select  the  correct  one  for  processing.  LADDER  does  not  normally  operate  in  this  mode, 
however,  since  determination  of  all  possible  interpretations  is  time-consuming.  Moreover,  it 


7.  Datacomputer  Version  5 User  Manual;  Computer  Corporation  of  America.  Cambridge  MA.  July 
1978. 

8.  The  Datacomputer  A Network  Data  Utility,  by  T Marill  and  D Stern:  AFIPS  Conference 
Proceedings,  vol  44,  May  1475.  p 389-345. 
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is  assumed  that  the  incorrect  response  will  encourage  the  user  to  rephrase  his  question  less 
ambiguously  By  and  large,  the  first  interpretation  generated  by  the  system  is  the  best  anyway : 
presumably  , little  would  be  gained  by  the  extra  processing  time  of  the  alternate  mode  I his 
trade-off  is  unavoidable,  at  least  until  the  natural  language  query  sy  stem  has  better  under- 
standing of  context  and  nuances  of  meaning  Since  this  discussion  is  primarily  concerned 
with  modifications  to  LADDER  'hat  involve  moderate  effort  but  are  hoped  to  result  in  sub- 
stantial improvements  in  operational  utility . ambiguity  resolution  remains  an  open  issue. 

Although  a natural  language  sy  stem  cannot  in  general  anticipate  user  queries,  there 
are  circumstances  for  which  it  can.  1 o.  example,  an  operator  may  ask  "WHA  1 SHIPS  AK1 
WITHIN  500  MIL  1 SOI  1111  PI-COS’"  l'o  determine  the  response,  the  system  finds  first 
the  position  of  the  PI  COS.  then  the  positions  of  all  other  ships.  I or  each  ship,  the  distance 
to  the  PI  COS  is  calculated  Pilose  within  500  miles  are  stored  in  the  response  list  Since,  in 
this  case,  the  data  base  management  sy  stem  has  to  access  ship  positions  in  the  I RACKH1S1 
tile,  there  is  little  cost  tie  time)  involved  in  also  retrieving  auxiliary  information  such  as 
course  and  speed  from  that  tile  Furthermore,  the  SHIP  relation  was  also  accessed  to  deter- 
mine ship  names  from  the  positional  information.  (TRACKH1ST  uses  ship  L'lC  and  VCN.  not 
the  ship  name  per  se.)  Therefore  data  from  that  file  could  be  added  to  the  auxiliary  buffer 
(such  as  ship  class,  nationality  and  ty  pet.  The  extra  attributes  are  part  of  the  tuples  already 
located  for  the  essential  information:  no  extra  searching  time  is  necessary  to  find  these  values. 
When  the  user  is  presented  with  the  requested  data,  such  as  simply  a list  of  ship  names  in  the 
above  example,  the  system  could  ask  "DO  YOU  CARL  LO  SI  1 MORI  INI  ORM  \ 1 ION 
It  the  user  answers  "y  es."  the  sy  stem  would  display  the  amplify  mg  information  immediately 
without  having  to  pass  a new  IDA  query  to  the  data  base  management  system  tor  processing. 
For  general  queries,  the  system  would  have  to  be  much  more  selective  to  ensure  ( 1 i that  the 
amplify  ing  information  does  not  repeat  data  contained  in  the  query  response  (except  for 
identification  of  the  objects  in  question)  and  (2)  that  the  additional  data  relate  to  the  cor- 
rect objects  (those  contained  in  the  response!  rather  than  to  intermediate  values  used  to 
calculate  or  qualify  the  result  For  example,  if  the  user  asks  "WHA  F SHIPS  AR1  I ASTFR 
THAN  Till  1 ASTI  ST  US  SITU’",  no  amplifying  information  should  be  retrieved  for  the 
"FAS  11  SI  US  SUB." 

I ADDER  has  the  capability  to  refer  to  a previous  query  to  resolve  pronominal  refer- 
ences and  elliptical,  or  incomplete,  queries.  Additionally . a previous  query  . numbered  by  the 
INTFRLISP  sy  stem,  can  be  reentered  and  processed  by  using  the  REDO  command,  specify  - 
ing the  query  number  or  range  of  query  numbers  to  be  "redone."  (See  ret  b for  a description 
of  the  RFDO  command.)  For  this  capability  to  be  truly  useful,  the  operator  would  need  to 
preserve  earlier  portions  of  his  transaction  on  hard  copy  to  refer  to  those  numbers.  Fre- 
quently used  queries  or  a complicated  series  of  questions  can  be  defined  as  a single  query  by 
using  the  macro-paraphrase  feature  of  LADDFR.  For  example,  the  following  questions 
might  commonly  be  asked  in  a search  and  rescue  operation  in  which  PI  COS  is  assumed  to 
be  the  name  of  a distressed  vessel: 

WHAT  SHIPS  ARE  WITHIN  500  MILES  OF  Fill  Pi  COS? 

WHAT  IS  THEIR  READINESS’ 

WHICH  OF  THESE  SHIPS  HAVE  A DOCTOR  ABOARD.’ 

HOW  LONG  WOULD  IT  TAKE  THESE  SHIPS  TO  R1  ACII  THE  PECOS? 

The  simple  statement  "SARSITILATION  AROUND  PECOS"  can  be  defined  as  a paraphrase 
of  the  given  series  of  questions.  Moreover,  the  question  is  not  restricted  to  the  PECOS:  if 


l>.  INTFRLISP  Reference  Manual,  by  W Teitelman.  Xerox  Palo  Alto  Research  Center  Palo  Alio  C A. 
December  ll>75. 
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any  other  ship  name  is  used,  LADDER  will  make  the  appropriate  substitutions.  This  capa- 
bility is  analogous  to  the  stored  query  capability  of  the  operational  NWSS  (Naval  WWMCCS 
Software  Standardization)  Query  Module  (ref  10).  In  that  system,  queries  composed  in 
fixed  format  can  be  placed  into  a Stored  Query  File  for  future  use.  When  recalled,  the 
queries  may  be  modified  and/or  passed  to  the  Query  Module  for  processing.  In  each  of  the 
above  requests,  LADDER  recomputes  the  distances  from  all  ships  to  the  PECOS  to  satisfy 
the  pronominal  references  to  “SHIPS  WITHIN  500  MILES  OF  THE  PECOS.”  It  would  be 
more  efficient  for  the  query  system  to  place  the  actual  ship  names  satisfying  the  given  qual- 
ification into  its  memory  and  to  use  that  list  to  determine  the  responses  to  subsequent 
references. 

The  features  just  discussed  comprise  the  ability  of  the  query  system  to  remember 
prior  interactions  and  to  provide  recall  so  as  to  simplify  operator  composition  of  new  or 
repeated  queries.  Elliptical  and  pronominal  references  represent  an  immediate  recall  of  the 
user’s  inputs;  macro-expansions  (ie  stored  queries  in  the  Query  Module  context)  are  a more 
permanent  recollection  of  the  user's  information  retrieval  needs.  When  elliptical  and  pro- 
nominal references  are  used  in  conjunction  with  the  grammatical  modifications  discussed 
previously,  a query  system  can  be  envisioned  that  would  no  longer  be  a passive  recipient  of 
user  requests  but  an  active,  intelligent  assistant  that  aids  the  user  in  the  performance  of  his 
duties.  Based  on  a given  task,  an  appropriate  grammar  would  be  selected,  either  automatic- 
ally or  by  the  user,  to  profile  the  user's  information  requests.  Such  a mission  profile  would 
be  defined  by  the  contextual  grammar  and  by  stored  macro-expansions.  The  latter  would 
allow  the  user  to  easily  obtain  general,  task-oriented  information  typically  of  import  to  the 
given  mission.  Additionally,  amplifying  information  would  he  stored  for  the  user's  attention 
should  he  desire  to  view  it.  The  grammar  itself  would  further  adapt  to  the  relevant  context 
throughout  the  interaction  by  determining  what  ships  or  aircraft  are  involved,  what  sensor 
data  are  necessary,  what  tracks  are  pertinent,  etc.  In  short,  the  query  system  would  provide 
the  environment,  or  mission  profile,  by  which  the  user  could  easily  and  efficiently  accomp- 
lish his  information  retrieval  tasks.  The  user  would  retain  the  option  of  asking  ad  hoc  queries 
in  order  to  obtain  further  insight  into  the  given  situation,  to  retrieve  data  unrelated  to  the 
current  context,  or  to  establish  a new  context  altogether.  With  the  traits  of  adaptability,  con- 
textual awareness,  and  flexibility  thus  incorporated,  the  query  system  becomes  responsive  to 
the  user’s  needs,  thereby  providing  the  intelligent  interpretation  of  his  requests  essential  to 
effective  utilization  of  the  system. 


INTELLIGENT  DATA  ACCESS 

Beyond  having  the  “intelligence”  to  comprehend  user  inputs,  a query  system 
can  exercise  some  degree  of  judgment  in  the  actual  access  and  retrieval  of  data.  Data 
discrimination  (providing  only  what  is  asked  for)  and  optional  response  amplification,  as 
introduced  in  the  preceding  section,  are  two  examples  of  such  judgment.  The  IDA  subsys- 
tems of  LADDER  have  been  found  to  be  adequate  for  a number  of  applications,  but  some- 
what difficult  to  use  when  applied  to  the  Navy  data  base  resident  in  the  NOSC/ACCAT 
system.  This  became  apparent  during  efforts  at  NOSC/ACCAT  to  expand  both  the  front-end 
grammar  and  the  IDA  schema  (lDA's  national  model  of  the  data  base  structure)  from  the 
limited  view  supported  by  the  Bluefile  data  base  (ref  1 1 ) to  a more  complete  Navy  context 

10.  NAVCOSSACT  Document  07A001 A UM-04,  Navy  WWMCCS  Software  Standardization:  Book  a 
Query  Module  User  Manual:  Naval  Command  Systems  Support  Activity,  May  1976. 

I I NOSC  Code  S.t71  Hr  rpt,  The  Relational  Model  for  the  Bluefile  Data  Base  (Revised).  November  l'*76. 
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represented  by  an  at-sea  command  and  control  center  data  base  (ref  12).  The  problems 
encountered  during  those  efforts  will  be  discussed  in  this  section.  Furthermore,  possible 
approaches  to  data  access  to  solve  these  problems  will  be  suggested. 

Currently,  IDA  contains  a very  straightforward  algorithm  for  determining  what  files 
tie  relations)  are  to  be  used  to  obtain  the  data  requested  in  a query.  (As  discussed  previously, 
the  user’s  query  is  translated  to  IDA  query  format  by  the  front-end  grammar.)  At  each  iter- 
ation of  the  algorithm,  the  system  possesses  a list  of  relations  already  chosen  (empty  in  the 
First  iteration)  and  a list  of  fields  in  the  query  which  have  not  yet  been  covered  by  chosen 
relations,  ie  that  cannot  be  found  in  the  attribute  lists  of  the  relations  already  selected.  The 
next  uncovered  field  in  the  query  is  selected,  and  the  algorithm  attempts  to  find  a relation 
that 

( 1 ) covers  the  selected  field, 

(2)  has  a direct  link  (via  a common  attribute)  to  a relation  already  chosen  (if  one 
exists),  and 

(3)  covers  as  many  uncovered  fields  as  possible. 

IDA  processes  the  query  from  left  to  right,  attempting  to  minimize  the  number  of  relations 
which  will  need  to  be  accessed.  For  example,  given  the  relations  (and  associated  attributes) 

SHIP:  (NAME  CLASS  TYPE  PTP  TPD  CONVOY) 

SHIPCLASS:  (CLASS  TYPE  LGH  DRAFT) 

IDA  accesses  only  the  SHIPCLASS  relation  to  determine 
(?  LGH)  (CLASS  EQ  BELKNAP') 

(ie  WHAT  IS  THE  LENGTH  OF  BELKNAP  CLASS  SHIPS’),  since  both  LGH  and  CLASS 
are  found  in  that  file.  For  the  IDA  query 

<?  LGH)  (NAME  EQ  ’FOX') 

(ie  WHAT  IS  THE  LENGTH  OF  Till-  FOX?).  IDA  generates  two  retrieval  requests  to 
the  data  base,  for  simplicity  also  shown  in  IDA  query  language  format,  of  the  form 

IN  SHIP  RELATION:  (NAME  EQ  ’FOX')  (?  CLASS) 

IN  SHIPCLASS  RELATION:  (?  LGH)  (CLASS  EQ  ‘BELKNAP’). 

where  (CLASS  EQ  ‘BELKNAP’)  was  the  response  to  the  initial  query.  In  this  example,  IDA 
builds  a reference  to  both  the  SHIP  and  SHIPCLASS  relations,  essentially  generating  the  join 
of  these  two  relations  over  the  common  attribute  CLASS.  This  file  linkage  information  is 
also  contained  in  the  structural  schema  known  to  IDA.  In  actual  system  testing,  however,  it 
was  found  that  IDA  does  not  always  consider  files  having  direct  linkage  to  ones  already 
chosen,  but  simply  selects  any  file  connected  to  the  chosen  file  and  containing  the  requested 
field.  The  current  IDA  does  not  determine  the  shortest  path  to  use  for  data  retrieval,  but 
instead  selects  whatever  path  it  finds  first  (whether  it  is  a direct  path  or  an  indirect  one 
through  several  intermediate  nodes).  Although  an  optimization  procedure  in  such  a case  may 
be  time-consuming,  processing  time  spent  for  that  purpose  may  be  considerably  less  than  the 
data  retrieval  time  that  results  from  a long  access  path  in  which  the  values  of  intermediate 
links  must  also  he  found  in  the  data. 

The  source  of  this  problem  relates  to  problems  discussed  in  the  previous  section. 

When  the  front-end  grammar  is  given  the  request  "WHAT  IS  THE  SPEED  OF  XYZ?”  the 
attribute  “SPEED"  is  translated  to  a specific  field  name  used  in  the  data  base.  For  example, 

12.  NOSC  Code  8321  Itr  rpt,  Expanded  Relational  Models  for  the  Fleet  Command  Center  and  At-Sea 
Commander’s  Databases,  March  I D 7 7 . 
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if  XYZ  is  a ship,  the  current  speed  of  XYZ  is  found  in  attribute  PTS  of  the  TRACKHlS'l 
relation.  (The  examples  to  follow  will  refer  to  a modified  Bluefile  data  base  structure 
created  at  NOSC/ACCAT.)  Without  a context-dependent  translation,  the  grammar  makes 
the  same  translation  for  SPEED  (ie  to  attribute  PTS)  if  XYZ  is  an  aircraft  type  or  a flight 
number.  Context-specific  patterns,  on  the  other  hand,  would  ensure  that  aircraft  attribute 
names  would  be  associated  with  aircraft,  flight  attributes  with  flights,  ship  attributes  with 
ships,  and  so  on.  The  trade-off  is  in  the  simplicity  of  a generalized  grammar,  as  compared  to 
problems  of  development  and  maintenance  of  a context-specific  grammar.  One  attempt  at 
a compromise  is  exhibited  by  reconsidering  the  above  example.  If  XYZ  has  been  interpreted 
as  an  aircraft  type,  IDA  is  given  the  query 

(?  PTS)  (A1RNAME  EQ  ‘XYZ'). 

In  the  IDA  schema,  PTS  is  defined  as  an  attribute  belonging  to  relations  TRACKH1ST  and 
AIRCRAET,  but  having  a synonym  of,  say,  MAXSPEED  in  the  AIRCRAFT  relation.  This 
allows  IDA  to  make  the  necessary  translation  to  the  context-specific  attribute.  Operation- 
ally. however,  IDA  has  been  found  to  be  in  error  in  similar  situations,  incorrectly  answer- 
ing the  query 

(?  PTS)  (NAM  EQ  ‘XYZ’) 

(when  XYZ  is  a ship)  by  accessing  the  AIRCRAFT  file  for  PTS.  Since  the  attribute  PTS  is 
not  found  in  the  SHIP  relation,  the  first  relation  found  to  cover  the  field  is  selected,  rather 
than  the  first  relation  directly  linked  to  the  one  containing  the  specified  field.  If  the  order 
of  the  query  is  changed  to 

(NAM  EQ  ‘XYZ')  (?  PTS) 

it  will  be  processed  correctly,  suggesting  a modification  to  the  algorithm  whereby  relations 
covering  qualified  fields  are  selected  first,  relations  linked  to  those  selected  by  a common 
attribute  are  next  checked  for  uncovered  fields,  then  relations  indirectly  linked  through  one 
or  more  intermediate  relations  are  checked  for  remaining  uncovered  attributes.  By 
appropriate  search  procedures,  it  may  be  possible  to  actually  determine  the  shortest  access 
paths  to  the  required  data  in  terms  of  the  number  of  relations  accessed,  including  intermediate 
relations. 

If  the  context  is  recognized  by  the  grammar  (eg  a specified  aircraft  name  is  associated 
to  “A1RNAMF."  in  the  IDA  query),  the  simplest  solution  may  still  be  to  perform  the  neces- 
sary translation  of  the  attribute  category  (eg  SPEED)  to  specific  attribute  labels  associated 
with  the  identified  context.  The  translation  could  occur  before  or  after  IDA  is  called  to 
process  the  IDA  query  language  translation  of  the  user's  input.  Nonetheless,  the  above  dis- 
cussion covers  a more  general  situation:  no  matter  how  well  the  query  context  is  specified, 
multiple  file  accesses  through  one  or  more  intermediate  relations  will  always  be  a possibility. 
Efficient  determination  of  the  shortest  access  paths  would  enhance  system  operation  in  all 
cases. 

Grammatical  adaptation  to  user  context,  as  proposed  in  the  previous  section,  leads  to 
consideration  of  the  possibility  of  dynamic  data  base  conformity  to  user  requirements.  At 
least,  the  query  system's  “view”  of  the  data  base  structure  could  adapt  to  context  by  con- 
centrating strictly  on  those  access  paths  recognized  as  satisfying  the  user'  information  needs. 
By  restricting  the  number  of  relations  used,  shortest  path  determination  become  considerably 
more  efficient,  particularly  when  the  total  number  of  relations  in  the  data  base  is  large.  Fur- 
thermore, the  data  base  remains  unchanged  , only  the  internal  model  of  the  data  base 
structure  changes.  In  the  IDA  context,  the  system  would  construct  a data  submodel  on  the 
basis  of  user  queries,  gradually  shifting  from  the  total  structural  model  to  the  submodel  as 


the  Litter  becomes  more  capable  ot  covering  all  fields  of  the  user’s  requests.  Using  a modt- 
lieil  covering  algorithm,  as  discussed  above,  undefined  links  or  attributes  encountered  during 
processing  would  signal  an  incomplete  representation  ol  the  structure  in  the  submodel, 
whereby  the  total  model  would  be  used  to  determine  the  response.  1 inks,  relations,  and 
attributes  in  the  total  model  used  to  generate  the  query  response  but  not  yet  incorporated 
into  the  submodel  would  then  be  added  to  the  submodel,  providing  a broader  coverage  tor 
subsequent  queries,  fhe  resultant  structure  would  support  the  specific  information  retrieval 
task  defined  In  the  user.  As  with  contextual  grammars,  con  text -specific  submodels  of  the 
data  base  structure  provide  fundamental  building  blocks  of  the  mission  profile  concept 

An  even  more  ambitious  goal  is  to  create  a context-specific  partition  ot  the  data  base 
itselt  either  a physically  separate  substructure  or  a collection  of  pointers  that  allow  rapid 
anil  direct  access  to  portions  of  the  data  base  of  interest  to  the  user.  The  first  alternative 
requires  creation  ol  substantial  updating  features  to  ensure  the  integrity  of  data  in  the  sepa 
rate  partition.  Ill  is  is  similar  to  the  update  problem  for  a network  of  distributed  data  bases, 
many  of  which  have  certain  data  elements  in  common.  Maintaining  data  integrity  and  cur- 
rency in  a distributed  data  base  is  a nontrivial  problem.  I he  Ouery  3 sy  stem,  which  is  a 
structured  l uglish  query  sy  stem,*  creates  a ■’snapshot”  of  a portion  of  the  data  base  by 
copying  entire  tuples  of  a relation  as  specified  by  the  user.  No  attempt  is  made  to  keep 
the  values  of  those  elements  current  with  the  main  data  base,  however.  I he  second  alterna- 
tive demands  a great  deal  ol  knowledge  on  the  part  of  the  query  system,  specifically  w ith 
regard  to  the  phy  sical  location  of  data  in  the  machine,  and  requires  a detailed  interlace  with 
the  data  base  management  sy  stem.  I he  advantage,  of  course,  is  that  although  data  are  not 
changed  or  copied,  explicit  access  paths  to  the  data  ol  interest  are  created,  greatly  reducing 
the  long  search  and  retrieval  times  w hich  can  occur  for  large  files.  Implementation  details 
for  such  a scheme  are  beyond  the  scope  of  this  paper,  particularly  with  regard  to  specifica- 
tion of  necessary  interactions  between  in  this  case  I \DI)I  K and  Datacomputer.  I he 
concept  does  appear  worthy  of  investigation  prior  to  defining  firm  query  system  requirements 
for  Navy  command  and  control  use. 


IN  I I LLKil  NT  SUPPORT  Ol  USl  K INTI  R U HONS 

Ihe  previous  two  sections  have  discussed  three  methods  by  which  a query  system 
can  assist  a user  semantically  by  correctly  interpreting  the  meaning  of  his  inputs,  by  facili- 
tating the  retrieval  ol  desired  data,  and  by  creating  an  env  ironment  to  ful till  specific  mission 
or  task-related  information  requirements  I he  discussions  dealt  with  how  the  system  is  to 
process  queries,  thereby  focusing  on  the  internal  functions  ol  the  query  sy  stem  In  this  sec 
tion.  the  emphasis  shit  is  to  the  system  "I  rout  end.”  the  user-sv  stem  interaction  itself, 
although  the  presentation  does  not  address  the  phy  sical  man-machine  interface  tie  how 
the  user  interacts  with  the  terminal ).  I low  the  sy  stem  interacts  with  a user  is  of  primary 
concern  since  it  determines  how  "comfortable"  the  user  will  be  with  respect  to  Ins 
emotional  and  mental  state  ot  mind.  Many  features  can  be  incorporated  to  create  a 
user-friendly  environment,  such  as  prompting,  tutorial  assistance,  user  specified  formats 
for  output  responses,  meaningful  and  precise  error  diagnostics,  protection  against 
system  failure,  auxiliary  terminal  activity  during  long  query  processing  ami  retrieval 

*A  version  ol  Qtieiy  3 is  resident  on  the  Univeisity  ol  Southern  ( .ihlomi.i  Inloinutton  Sciences 
Institute  System  1 Dll'  kl  30  40  ( ARI’A  node  I to),  on  line  document  at  ion  ts  .o.ul.iMe  on 
t li.it  system. 
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delays,  and  so  on.  Since  combinations  of  such  features  can  be  found  in  nearly  any  user- 
interactive  system,  the  implication  exists  that  making  the  environment  more  benign  enhances 
system  utility.  This  contention  is  not  argued  here;  it  is  accepted  as  intuitively  obvious. 

Conceivably,  the  user-system  interaction  could  become  even  more  friendly  if  it 
could  characterize  the  capabilities  of  each  user  in  some  way  and.  on  the  basis  of  this  charac- 
terization. could  provide  a level  ot  assistance  and  guidance  commensurate  with  the  preceived 
abilities  and  limitations  of  the  user.  The  characterization,  or  “profile”  (hence,  "user  profile  '). 
would  be  generated  from  previous  interactions  with  the  user.  Evaluation  criteria  could  be 
defined  to  assess  the  user's  capabilities  with  respect  to  various  aspects  ot  system  operation 
and  his  knowledge  of  system  features.  Using  this  model  of  the  user’s  capabilities,  the  system 
would  control  certain  portions  of  the  user-system  interaction,  such  as  prompting,  tutorial 
assistance,  and  other  areas  for  which  the  system  knows  that  the  user  requires  aid.  1 he 
profile,  therefore,  would  not  only  reflect  specific  features  desired  by  and  for  the  user  in  the 
traditional  sense,  but  would  also  contain  the  system's  understanding  of  the  user's  current 
level  of  proficiency,  frequency  of  use  (to  determine  whether  a refresher  course  is  warranted 
after  a long  period  of  inactivity  1 and  other  characteristics. 

The  user  profile  is  clearly  distinct  from  the  concept  of  mission  profile  in  that  the 
former  characterizes  the  user  and  his  preferences  and  abilities,  whereas  the  latter  character- 
izes the  user’s  areas  of  concern,  data  access  paths,  and  query  grammer  appropriate  to  specific- 
missions  and  retrieval  tasks.  The  user  profile  concept  may  be  expanded  even  further;  it 
may  be  possible  lor  the  system  to  generate  a model  ol  the  conceptual  approach  to  a prob- 
lem as  exhibited  by  a user,  particularly  with  regard  to  specific  types  ol  missions  or  tasks 
performed  frequently  by  the  user.  Repetition  of  tasks  provides  a statistical  base  from  which 
to  generate  the  profile.  By  observing  the  user’s  problem-solving  methodology  and  by  creating 
a model  of  these  processes,  the  system  would  become  an  intelligent  assistant  in  subsequent 
tasks,  prompting  for  information  or  automatically  presenting  data  in  the  logical  sequence 
appropriate  to  that  user’s  conceptual  outlook.  Together  with  mission  profiles,  then,  the 
system  would  contain  personalized  problem-solving  approaches  for  the  accomplishment  ot 
specific  tasks,  adapting  to  changes  in  the  user's  domain  of  interest  as  well  as  to  modifications 
of  the  user’s  analytical  approach. 

The  achievement  of  mission  and  user  profiles,  as  described  herein,  certainly  laces 
more  rigid  constraints  than  the  reaches  of  one's  imagination.  The  nature  ol  those 
constraints,  however,  has  not  yet  been  determined.  At  present,  implementation  ol  mission 
and  user  profile  concepts,  at  least  on  a preliminary  level,  is  considered  to  be  within 
current  computing  capabilities.  Within  an  experimental  environment,  such  as  that  provided 
by  the  ACC  AT  facility,  the  utility  of  such  applications  of  artificial  intelligence  to  query 
processing  in  a Navy  command  and  control  environment  can  be  measured  and  evaluated, 
thereby  supporting  the  generation  ol  functional  requirements  lor  future  systems. 


CONCLUSIONS 

LADDER  lias  been  found  to  be  an  extremely  useful  tool  both  in  determining  the 
utility  of  natural  language  query  systems  for  information  retrieval  in  a command  and  con- 
trol environment  and  for  studying  user-supportive  features  which  may  enhance  the  utility 
of  any  query  system.  These  features  induce  the  concept  of  an  intelligent  assistant,  a query 
system  which  actively  aids  the  information  retrieval  process  by  ( 1 ) delineating  the  scope  ol 
the  problem,  (2)  performing  the  routine,  preliminary  footwork  that  establishes  the  context 
for  the  user,  and  (3)  assisting  the  user's  interactions  and  query  processing  through  intelligent 
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guidance  .mil  organization  of  mlonn.it ion  I ADI )l  K prov ides  an  effective  framework  from 
which  | ho  feasibility  ol  such  concepts  can  Iv  proven,  both  from  a theoretical  standpoint 
and  with  respect  to  actual  user  interactions  in  comniaiul  and  control  situations 


RI  COMMI  NIUTIONS 

1 Modify  I ADDI  K to  incorporate  user  profile  anil  mission  profile  concepts 
described  herein 

2 Conduct  experiments  with  operational  users  to  examine  the  effects  of  these 
concepts  on  performance  ol  the  query  system 
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This  appendix  shows  the  modifications  made  to  the  LADDER  grammar  to  demon- 
strate the  feasibility  of  the  adaptive  grammar  concepts.  No  attempt  is  made  to  describe 
precisely  how  the  modifications  accomplish  the  desired  effects,  since  this  would  require 
substantial  discussion  of  the  organizational  structure  of  the  grammar  as  well  as  the  process- 
ing logic  performed  by  LADDER  For  details  of  the  mechanics  of  these  operations,  see 
LADDER  documentation*  or  contact  NOSC/ACCAT  analysts  familiar  with  these 
procedures. 

•Hendrix  GG.  Technical  Note  ITS.  [lie  LIFER  Manual:  A Guide  for  Building  Practical  Natural  Language 
Interfaces.  SRI  Artificial  Intelligence  Center.  Menlo  Park  CA,  February  W77. 

Final  Technical  Report.  Project  47pT.  Mechanical  Intelligence:  Research  and  Applications,  by  FD 
Sacerdoti  (ed).  SRI  International.  Menlo  Park  CA.  December  1477. 


PROCEDURES 


(LISTQUOTE 
CLAMBDA  (L) 

(ENQUGTF  ( SUESTR  IMG  ( MKST?  ING  L) 

2 -?1) 


(TAIL. END 
[LAMBDA  (X) 

( SETQ  X LIFER.  REMAINING.  INPUT) 
(SETG  LIFFR. REM* INING. INPUT  NIL) 

( SETG  I.TFER.  MULT  I- WCRn  YD) 

(CHECfWITHUSER 
[LAMBDA  (X) 

( PRTG  (V) 

( 5ETG  Y ( >M?.PES GLUTTON  X)) 
(RETURN  (WANT. EG  (CDR  Y) 

(CAR  YD) 


(AMB. RESOLUTION 
[LAMBDA  (X) 

(SELECTQ  CAS^USFR  30  (QUOTE  N ) 

(CJNCAT  (ANATOM  (SUcST«TNr  X 2 -2)) 

" IS  NOT  RECOGNISED  AS  A V AT  T p N A M E . 

IS  IT  INTENDED  TO  PE: 

A.  SHIP 

B.  PORT 

C.  AIRFIELD 

D.  AIRCRAFT 
?.  AIR  TRACK 

F.  SQUADRON 

G.  cLTCPT 

H.  SURFACE  TPACK 

I.  SENSOR 

J.  COMMUNICATION  DFVICF 

K . APON 

L.  WEATHER  AREA 

N.  NOME  OF  THE  ABOVE 

(ENTER  THE  LETTER  cnRRESPONL I NG  TO  THF  CESIIED  INTERPRETATION  OE 

(MK  A TOv  (SUBSTRING  X 2 -2)) 


ENTER  AN  'S'  IF  NON F OF  THE  ABOVE  APPLY.) 
") 
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• I 


[ 


(QUOTE  ((A 

• 1 

• 

SFTP") 

(B 

M 

• 

PORT") 

(C 

II 

airfielp") 

(n 

#1 

• 

1 TRCRAFT") 

(F 

•1 

• 

AIR  TPAOX") 

(e 

M 

• 

SQUADRON") 

(G 

11 

FT.  I GUT" ) 

( H 

(t 

• 

S'JPFACt  TPACK") 

(T 

11 

• 

SENSOR" ) 

(J 

11 

■ 

COMMUNICATION  DEVICE") 

(K 

11 

• 

WEAPON") 

(L 

«• 

• 

UEATUEP  AP£A" ) 

( N 

"ONE 

OF  THFSF.") 

(A  (SPCLSOTU"  > ( GUCTc  N A V ) 

( GrCTO  N A1JF  > ) 


(2 


(C 

'D 

(F 

(F 


(r, 


r> 


(quote  <»:«vj.>))j 

(SPCL'T.TJF  X ( QUOTE.  PCSP) 

(QUOTE  <l'NQ.POPT>) 
(QUOTE  <CCPT1>) ) ) 

(FT  t LPSF.TUP  X (QUOTE  FLDNAMF ) 

( QU07  F <AFIELDS>))) 
(t'IF.LnSrTM-  X (quote  a:<»namf> 


( CI FLDS^TUP 
( r T "L  H Sr  ?np 
(FTFLCSFT’JP 
(ri*LrzrTVD 


(QUOTE  XA^CRAFT. FAMES)))) 
X ( OMOT  v ATRAC*) 

(Quarr  <A T kTRA  CKS>  ) ) ) 

x (Quri*7  a I p ut c ) 

(QUOTE  <SQUADTDS>))) 

X (QUOT1’  FLTMD 
(QU^TF  <FL ICH?\P>  ) ) ) 

X (QUGT*  TRACK  NO 
( QUQT F <Tr!C:<’JIST>))) 


(I  (7ISLPS*TUP 
(J  (FT ELTSF  TUP 
(*  (FI ELDSFTUP 
(L  (FTtLrSFii:r 
(PROG  NIL 


X (QUOTE  SfcNSNAME) 

( QUOTE  <rS(rNSCPNAMFS>  ) ) ) 
X ( QUOTE  ,'3MMV  Av 6 ) 

( QUOTE’  <CCHV  UVFS>)) ) 

X (QUOTE  vfPSNAVF) 

( Q'JTT1'  <**NNAMFF>))) 

X (QUOTE  KtXAFES) 

( QUOTE  < W A R t A S > ) ) ) 


( Pr  TNT  "FIFASF  T^V  TUF.  QU^ry  AGAIN. 


" NIL) 


( RFTFROV  ( QUOTE  PSPSE) 
NIL  T I ) 


(FIFLD£FTt,P 

CLAVBDA  (NA'*E  FLD  SYV.C  ) 

( PKOG1  (CONS  (LI  ST QUOTE  NAVE) 

*LO) 

(CON'' 

( (FQF  (COUNT  NAME) 

1) 

(MS  SYMB  NAIF)) 

(T  (FP  NAME  (M*  ATOM  (SUBSTRING  NAME  2 -2)) 
SYMP)) 


| * 


j 

-4 


3 


3 


1 
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(OSERSPECIFIEO 
(LAMBDA  (SYMB  X) 

(SELECTO  (ASKUSER  30  (QUOTE  N) 

(CONCAT  "THF  SPrCIFT ED  NAME,  " 

(SUBSTRING  (MFSTRTNG  X) 

2 -2) 

",  IS  NOT  CONTAINED  IN  THE  SVT  LF  NAMES 

n 

CPROG  NIL 

( CONI) 

((NOLI  SYMB ) 

(PFTL'PN  "FOR  THIS  OPJFCT")) 
(T  (RETURN  (MESTRING  SYMB) 


IF  YOU  WANT  T«k  S''ECIE[tO  NAME  PUT  j*;TO  THIS  ScT  FOR  l AT LR  USE,  ENTER  \ Y 
(FOR  'YES').  OTHERWISE,  ENTER  AN  N (FOR  'NO'). 

") 

NIL) 

(Y  X) 

(PROG  NIL 

(PRINT  "PLEASE  TRY  TMF  QUERY  AGAIN..."  NIL) 

(RFTFRON  (QUOTE  PARSE) 

NIL  T3) 


(S1KGL  E/MULT  7 PL  £.  WORD.  NA.MF 
CLAMBDA  (X  SING  MULT) 

(PROGN  C CONI) 

( ( FQD  (COUNT  X) 

1 ) 

(USER  SPECIFIED  31 «G  y) 

(VS  SIFT  X)) 

(T  (T,S"RS°'rCIFl  f P vnj  t X) 

(CGND 

((OR  (EQUAL  ‘O'LT  (CUJIF  <NA”F>)) 

( EC  J A L MULT  (QUOTE  <PCPT1>))) 

(rP  X (f,  T STQ'JOTR  X) 

'ULT)) 

(T  (FP  X (MXATJv  ( BURSTS  I ?.T  v 2 -".)) 

«'JLT  I 

(LISTQUOTE  X]) 

(F0201 

CLAMBDA  ML 

(WANT.  EG  ( QUi'T *•  TRACXNU) 

( S I NCL^/^UI  " I PL  F . WCrR  . N AME  <1  Nr)FEINlTE>  (QUOTE  <TRA  CFHTST>  ) 

(CUCTF  <.  TR  ACNH  I ST>  1 ) 

( F0202 

CLAMBDA  ML 

(WANT .FC  ( QUOTE  ATRA  Cv  ) 

( SIN GLF/VUL TIP LL.WOkD. NAVE  <TNDkFINITE>  (QUOTE  <A  I PT^AOK  S>  ) 

(OHOTc  < A TRTH AC*S>)  ) 
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PRODUCTIONS 


C < .*  CFT  > ( ( ( < A T VC*K  A rT . N A JS  > ) 

C.TSTGliTT*  (LTST  <A  trco»^T.NAM?T>)  ) ) 
f(<’ATt?CR,FT>  CTRCPAFT.KAVFS>) 

(LISTGUCTF  (LTGm  <AIkCRAFT.NA“FF>))  ) 

((<ATR~sArT>  <T  '4P  Fr  I KTTc>  ) 

( ri?!CCc/?i"LTirLP.Ir.CFr'.NAMF  <'TN"',~FTNITF'>  (QTJCTP 

<.A  TRCRAFT.NA'TF*S>  ) 
(QU3TE  <AIKCRArT.NAFES>:< 

c < A T RF  I "I  .G  ■>  ( ( ( <*  F T c f 'SFTFC^S>) 

( L T S TGIIPT  c (LTST  < AF JFL^Sb  ) ) ) 

( (<  F T i L ^ ° P F ~ > < INOFr  TNITF  > ) 

( S l V C L - / * ti  L ? I P L p . v f!  C L . N « *'  ? < I VCTF  T KTTF>  (C’JCTF  (A^IFL^SJ) 

< «FT  c!lCS>  ) ) ) 

( (<  Ar TFLPS>) 

(l.TST!'/JPTF  (LIST  <A-TtLP^>i 

c<’CQMM.''tvrcfc>  ( ( ( <r1]f',<sPFC,»  o;c a^esm 
(L15T20PTK  (LTST  < : ■^•’■'MA  •*FS  > ) ) ) 

( ( <cnvvs?i'c>  < T .VP LF  I VJTfc  >) 

( FT  NCI. !• / 'U'LT I"L p C0"'.  N * ViF  < T NHFF I NTTO  (t?UCTr  <CCVVNA MFS>) 

(GUCTfc  CPy^NA VPS ) ) ) 

( ( cn^Nf  *-*fs>  > 

(!.TSTQL,f,r"  ( L T £ T < A.IFS>  .1 

C<FLTCHT>  (((<r'uTGHT.M>  c F L I C H T N H > ) 

(I  I FTC-TT'-'  ( f.  T S 7 <’F,.T'JT.‘«r  '>')  ) ) 

'('FL  Jrir.i\2'>  cTVi'if 

( F I ,NCL  F/w,,LT  I PL l?.  * CFG  • N A ,<v  < T LP’-'r  I N TTF  > (CUCTF  < FL  I CHT  ND>  ) 

(G'TTF  <*l TGUTNC>) ) ) 

( f <r F L TC'I?,,n>  > 

(LTSTPTIPTP  (LTCT  < f!  TGPf \P>2 
(<FrNTPM,,’^>  ( ( (<  PC  nfl'FO  <FP?T1>) 

<aCP:i>) 

( ( <F  CRTSP  >;~>  <T?Tr*FFT*'ITc.  >) 

( G I I'-’CLF/y  L’LT  T PL.  ^ .''GPD.  N A *•'"  < TN&FFTN  TTF>  ( C G n T F <'JMO.PCRT>) 

C GUPT i <PCFT1>))) 

( ( 7PCPT1 N ) 

<PUR71> ) ) ) 

C<S- NSUO  ( ( ( <St  NSUFSr  t(T>  <Sb.FSORN  AvfcS>  ) 

(L  T STGL'C  r1'  (LTST  < SFNSPR*!AVF.S>  ) ) ) 

( ( f S F N S G k S f ’ t P > <THr  FFI.NTTr>) 

(<'TNGf  r/-r'LTTPLF.^C^n.NA«F  ' n.’DFFINTTF>  ( Q !J  T T F <SFNSCPNAM5b>) 

( QUOTE  <FFNSCRNAVFS>))) 

((<bFNSOHNAvFS>) 

(LISTOUrTF  (LTST  <SFMFC^NAMFS>3 
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(<  SH I PPNTR  > (( (<SHIP5PKC>  < A M K > ) 

< N A m E > ) 

( (<SKIPF°EO  <’TNr>KFINTTc'>) 

(SINGLE/MULTIPLE. vOPn.NAMF  <P:OFFTNTTE>  ( GUOT  F <UV  Q.  KA  MF>  ) 

( QUOTE  < F A V E > ) )) 

((<NAMF>) 

<KA«fc>)) ) 

[<SCUADRCN>  (((<SQ'JAniDS>) 

( L I STQ'jnT  E (LIST  < SCU  A J I QS>  ) ) ) 

((<SCDPIO  <SGUA3T  )F>  ) 

( T.  I STQI’UT  E (L  T ST  < SOD  A D T OS > ) ) ) 

((<SQ0RN>  < INDEFINITE)) 

(SINGLE/MULTIPL . WORD . N A PE'  < l NDEF  T N I TF>  (QUOTE  <SQUADIPS>) 

(QUOTE  <SQl'AnTPS>Q 

C<TBAr,F.MMM>  ([(C5URFTRA  :*>  <"Tp  4 CKH  T ST>  ) 

(VANT.FC  ( QUOTE  TRACKNO) 

(LTSTQUOTS  (LIST  <TMACviiIST>"’ 

{{<  f MRr TP  ArK  N <’rNDFFTN!'TE>) 

(F0201  )) 

C (<AIRTR'0  <AIRTRACV’<;>) 

(WANT.c.0  (QUOTE  ATRAC*) 

(LIST  3”CTF.  a TFT  <M  PIP  AUK  F' ] 

((<’ATRTr'F>  < T\n  KF  IM  T t>  ) 

{ F0202  )) 

C(<TRAC*FTST>) 

(WANT.FQ  (QUOTE  TRA^KNC) 

(LTSTQUOTE  (LIST  <TRACK’rJTST>l 
( ( < A T RTR ACK  F > ) 

(WANI.EQ  (QUOTE  ATRAC*) 

(LTSTQUOTE  (LIFT  < A T PTF  A r K S> 1 

C < W t ATHFRARFA>  (((<VEXSPEC>  <VAREAS>) 

(LI STQUPTF  (LIST  < W ARE AS > ) ) ) 

( (<WAREAS>) 

O.  I STQUCTF  (LIST  < w A RF  A f.  > ) ) ) 

((<”ViSXSPFC>  <iyOFF TN TTF>  ) 

(SlN'OLE/MULTIPLF.VORn.  NAMF  < INDEFINITE)  ( QUOTF  <WAREAS>) 

(QUOTE  <KAPE»F>2 

C<*FN>  (((<WPNSPFO  <WPNNAMES>) 

(L  T ST  QUOTF  (LTST  < W PN»'  A * FS  > ) ) ) 

((<VPNSPFC>  < INOFFT*ITTE> ) 

(SINGLE/VULTIPLF.WGPD.NAWF  <INUFrTNTTF>  (QUC.TF,  <WPNNAMtS>) 

(QUOTE  <VPNN*MFS>))) 

( (<WPNNA*ES>) 

(LISTQUOTF  (LIST  < V P N V A U E S > ) 

(<ZZ1'»  ( ( ( <WHAT>  <Sr>  <ATTRTPUTF>  <OF>  <TN0CF.NAMF>) 

(NCONC  ( M # P T N ? < A TT D T RUT F> ) 

< INDFF. N A M F > ) ) 

((PRINTQUERY  <ZZ1>) 

LTFFP. TCP. GRAMMAR)  ) ) 


C<TNPFF.N»ME>  (((<DF.T>  ' r*n,  FF . N A V E > ) 
< INDEF.  NA*'S>  ) 

( C < A CP T> ) 

(WANT.FQ  ( Q n OT p ATPNAMF) 

< A rr T > ) ) 

((<SGUADROfJ>) 

(WANT. KG  (QUOTE  ATRUIC) 

^SQ'.'A  QPON>  ) ) 

( ( <FL  T CH" > ) 

(WANT. EG  ( QUOTE  FLTNQ) 

<FLIGrlT>)  ) 

((<£'?NFCF>) 

('•’ANT.EQ  ( QUOT  L SENSNA^f  ) 

< SFNsna> ) ) 

( ( <W«N>) 

(want.fc  (Qppte  *r?r1t’ 

<WPN>)) 

((<C CM ^.DEVICE?) 

(WANT  . fc Q ( QUOTc  COVvt.AK  t ) 
<CrMy.T>FVI,'E>)) 
((<SUTPFFT,,>) 

(’■’ANT.FQ  ( QUOTE  Nf  V ) 

<SHIPnNTcl>)  ) 

( ( <’TCPTrNTP> ) 

(WANT.  EG  (JlJOTc.  PrEP) 

<P0RTPNra  ? ) ) 

( ( < A T SF  I FLO ) 

(W  ANT.  FT  (G"PTE  Ft SNAMc  ) 

<■  A T RF I FT.P'*  ) ) 

( ( < X F A T H F R A R F A > ) 

(WANT.tQ  (QUOTE  WtX’kFA) 
<’ftr57l,r’pf  PFA>)) 

( ( < T ” A C K . V U M > ) 

<TRACK.NUV>) 

( ( < I VL  EF I NT TF> ) 

( "PFCKW  T'HUSF'?  < I N P c F T N T Tl>  3 


\i 


FIXED  PHRASES 


(<AIRCRAFT>  ((All?  CRAFT  )) 

( ( AIR  PLANT!  ) ) ) 

(<AIRi'RK>  ((AIR  TRACK))) 

( <CfJMMbPFC>  ((CJ'<‘<  l)EV  U.  u ) ) 

( (CUT.UJNICATICNF  DEVI CF  ))) 

( <F I ELDSPcC>  ((AIR  FIELD)) 
((AIR  HAST))) 


( <POR  lb'1hC>  ((PURL  CF  C M 1 )) 
((PURL  CF  ) ) 

( ( i-IARH  )r  UF  ) ) ) 

( <SQL)RN>  ( ( S 1U  A ) (u  I NJABFk  ) ) 
( ( SOU  ADRUN  /*))) 


( <S'IRFi'RACK>  ((SIRFACF  TRACK))) 
(<WFXSPtC>  ((  RFAi'.lF'R  ART'))) 


( <WPNSPFC>  ((WtAPCN  i'Y:'t  ) )) 


SETS 


( <AI.<C!?.AHi>  ( AI  i?Cf?At-V  AIRPLANE  )) 

(<CJMMSPEC>  ( CGM'lUfJ  ICAi'I uHb  PAOIU  PECEIVKw  TPAOyUTTF’?  DEVICE  ) ) 
UFIHLJSPEO  (AI.-fsVSE  AI,!HF!.  ) i.  ASH  I- 1 iiL.  J ) ) 

( <FLI0HV..IU>  (i-U  JH.i  ) ) 

( <PJin-SP£C>  ( PO  Hi  PQPV-I.u— CAF.L  )) 

( <Sh'NSUKDr’r.C>  ( St-  ^Su'i  ) ) 

US'IIPSPEO  (PLUYVMM  SHIP  VFSShl.  )) 

( <SO'.'H  l>  (SODA-  :MjM  ) ) 

( <SU-iHT:lACK>  ( i'TACfC  )) 

( <HbX5PFC>  (API:  \ .E  \THHR  ) ) 

( <»<P  ISPbG>  ( 0 J A K MI.SSlf.F  OP'V , AJ-'CF  1 ,Ji  j m ' ) 

PREDICATES 

( < I H)hF  1 i 1 1 lV_>  AIL.  ) 
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